Komplexität reduzieren durch klare und einfache Schnittstellen

Jedes Tech-Unternehmen, das schon einige Jahre erfolgreich am Markt ist und mit mehreren Teams an einer ständig wachsenden Software arbeitet, ist auch mit stetig wachsender Komplexität vertraut. Die Build- und Deployment-Prozesse werden immer zäher und langwieriger; die Abstimmungen zwischen den Teams immer aufwendiger. Oft scheint die Softwareentwicklung sogar langsamer zu werden, obwohl das Unternehmen wächst und immer mehr Entwickler:innen dazukommen.

Ein erfolgversprechender Ansatz, um die Komplexität in den Griff zu bekommen, besteht darin, die Software zu schneiden. Grundsätzlich wird durch das Hinzufügen neuer Schnittstellen das Gesamtsystem komplexer, da zunächst einmal mehr Code (und ggf. auch Infrastruktur) notwendig ist. Es muss also einen Nutzen geben, der diese Kosten rechtfertigt. Dieser Nutzen liegt darin, dass nicht mehr das gesamte System in der Tiefe verstanden werden muss. Entwickler:innen können bei einem guten Schnitt große Teile des Systems und damit auch große Teile der Komplexität auszublenden. Jedes Team kann sich auf seinen Teil der Software konzentrieren und muss ansonsten nur die relevanten Schnittstellen verstehen. Für alles was hinter der Schnittstelle passiert, muss ein oberflächliches Verständnis ausreichen.

Das Schneiden von Software kann also auch als bewusster “Trade-Off” gesehen werden: Die Kosten für Schnittstellen werden in Kauf genommen, damit sich das Team besser auf einen Teil der Software fokussieren kann. Dass die Kosten dabei so gering wie möglich sein müssen, versteht sich von selbst.

Kriterien für einen klaren Schnitt

Es gibt immer viele Möglichkeiten, wie ein bestehendes System geschnitten werden kann. Um die Varianten sinnvoll zu bewerten, reicht es nicht aus, nur technische Aspekte zu beachten. Am Ende muss die ganze Organisation mit dem neuen Schnitt zurechtkommen. Für eine leichtere Bewertung haben sich folgende drei organisatorische Kriterien als nützlich erwiesen:

• Autonomie: Autonomie ist der zentrale Faktor, der es einem Team ermöglicht, schnell voranzukommen ohne ständig durch Anfragen blockiert zu werden oder selbst warten zu müssen.
• Purpose: Es darf kein Team geben, welches nur ein Sammelsurium aus zusammenhangslosen Einzelthemen bearbeitet. Idealweise hat jedes Team einen klaren Purpose, der sich in einem Satz formulieren lässt. Das Team agiert eigenverantwortlich, hat immer einen klaren Fokus und treibt eigenständig Themen voran, die diesem Leitsatz untergeordnet sind.
• Balance: Es sollte keine Teams geben, die bei jedem wichtigen Feature der Flaschenhals sind und auch keine Teams, die nur unwichtige Randthemen bearbeiten. Eine gleichmäßige Verteilung ist möglich.

Im Folgenden sollen diese drei Kriterien einmal exemplarisch an zwei bekannten Architekturmustern angewendet werden:

Schichtenarchitektur

Die klassische Einteilung in 3 Schichten ist eine sehr gute Idee, wenn es darum geht den Code (im Kleinen) klar zu strukturieren. Dennoch ist das Muster auf teamübergreifender, organisatorischer Ebene offensichtlich nicht sinnvoll: Die Schichtenarchitektur ist keine Struktur, die es einem Team ermöglicht, autonom zu arbeiten. Ein “UI-Team” könnte nichts umsetzen, ohne sich mit dem “Logik-Team” oder “Persistenz-Team” ständig abzustimmen. Außerdem müsste jedes Team Aufgaben aus allen Bereichen bearbeiten und hätte keinen klaren Fokus. Einen “Purpose” zu formulieren wäre nicht möglich.

Der datengetriebene Schnitt

Ein datengetriebener Schnitt ist ein weiterer häufig gewählter Ansatz. Beispielhaft an einem Portal für Weine erklärt, könnte es also ein System geben, welches alles über den Wein weiß. Weitere Systeme würden die für den Winzer, den Käufer oder Bestellungen bereitstellen.

Der Wein-Service muss für die Suche nur die offensichtlichen Basisdaten kennen: Preis, Name, Art, Artikelnummer und Jahrgang. In der Produktansicht will der Weinkenner die ideale Temperatur, Restzucker, Säure und Alkoholgehalt wissen. Beim Bestellvorgang sind wieder andere Daten relevant: Verfügbarkeit, Mengenrabatt, Versandkosten und mögliches Lieferdatum. In der Praxis kommen für scheinbar einfache Objekte schnell hunderte Werte zusammen. Ein Team, welches solch einen Service betreut muss sich mit vielen Vorgängen im gesamten Geschäftsprozess befassen. Vom anfänglichen Marketing bis zur abschließenden Rechnung müssen Daten geliefert werden. Fokus auf einen Teil des Prozesses oder ein Thema ist fast nicht möglich. Ein solches Team wäre auch als nicht wirklich autonom, da die Zusammenarbeit fast allen Abteilungen notwendig wäre.

Kontexte schneiden mit Domain Driven Design

Domain Driven Design gehört zu den Themen, die fast jedem Menschen im IT-Umfeld in den letzten Jahren begegnet sind. Zum Schneiden eines Systems wird im Grunde aber nur ein einziges Konzept aus dem riesigen DDD Werkzeugkasten benötigt: Der Bounded Context (dt.: begrenzter Kontext). Ein Bounded Context ist ein abgegrenzter Bereich in dem jeder fachliche Begriff genau eine klare Bedeutung hat.

Viele Begriffe haben im Alltag eine kontextabhängige Bedeutung, die die meisten Menschen intuitiv richtig verstehen, ohne sich dessen bewusst zu sein. So kann mit der Zeitung sowohl die einzelne gedruckte Ausgabe, als auch das Unternehmen gemeint sein. Der Begriff Schule kann die Institution (Lisa geht zur Schule) oder das Gebäude (die Schule ist marode) bezeichnen. Viele Softwaremodelle sind unnötig komplex, weil unterschiedliche Bedeutungen von fachlichen Begriffen nicht erkannt und im Datenmodell vermischt werden.

Ohne ein strukturiertes Vorgehen ist es allerdings nicht möglich, sinnvolle Grenzen für Kontexte zu finden, da die Bedeutungen von Begriffen innerhalb eines Unternehmens oft nicht so unterschiedlich sind, wie in den gerade genannten Alltagsbeispielen. Eine ideale Methode, um das “Big Picture” eines Systems zu erfassen und anhand von Events die Kontexte herauszuarbeiten, ist das Event Storming. Im nachfolgenden Blogpost zu diesem Thema werden wir das fiktive Weinportal mit Hilfe dieser Methode schrittweise und leicht nachvollziehbar zerlegen.